Протокол SSH версії 1 ¶

Перша метода автентифікації полягає у використанні файлів rhost або rhost.equiv у поєднанні із RSA-перевіркою хосту. Якщо машина, з якої долучився користувач, згадується у /etc/hosts.equiv або /etc/ssh/shosts.equiv на віддаленій машині, і назви користувача збігаються на обох кінцях, користувачеві дозволяється негайно зареєструватись. Також, якщо в користувацькому домашньому каталозі на віддаленій машині присутні файли ~/.rhosts або ~/.shosts, що містять рядок з назвою клієнтської машини з ім'ям її користувача, цьому користувачеві також дозволено реєструватися. Додатково, за умови, що сервер може перевірити клієнтський хост-ключ (дивіться /etc/ssh/ssh_known_hosts і ~/.ssh/known_hosts у розділі ФАЙЛИ), тільки тоді дозволяється реєстрація. Ця форма автентифікації, закриває дірки в безпеці, пов'язані з підробкою IP, DNS або маршрутизації. (Примітка для адміністраторів: /etc/hosts.equiv, ~/.rhosts і протоколи rlogin/rsh, загалом, небезпечні і необхідно заборонити, якщо прагнете безпеки.)

Друга автентифікаційна метода основується на RSA. Ця схема спирається на шифруванні на основі публічних ключів: існують криптографічні (шифрувальні) системи де шифрування і розшифровування відбувається завдяки двом окремим ключам, при цьому неможливо здобути ключ розшифровування при наявному ключі шифрування. RSA саме і є однією з таких систем. Ідея полягає в тому, що кожний користувач створює власну публічну/приватну пару ключів з метою автентифікації. Сервер знатиме публічний ключ і тільки користувач на клієнті володітиме приватним ключем.

Файл ~/.ssh/authorized_keys містить перелік публічних ключів, яким дозволено реєструватися на сервері. Під час реєстрації користувача, програма ssh вкаже серверу, яку пару ключів вона хоче використати для автентифікації. Сервер перевірить, чи цей ключ дійсний, і якщо так - пошле користувачеві (насправді програмі ssh, яка діє від імені користувача) виклик у формі довільного числа, зашифрованого користувацьким публічним ключем. Виклик може бути розшифровано тільки використовуючи відповідний приватний ключ. Клієнт повинен розшифрувати виклик за допомогою приватного ключа, доказуючи, що він знає приватний ключ (тобто є тим за кого себе видає), але не розкриваючи ключ серверу.

ssh втілює автентифікаційний протокол RSA автоматично. Користувач створює власну пару ключів RSA, запустивши програму ssh-keygen(1). Остання збереже приватний ключ у ~/.ssh/identity, і публічний ключ у ~/.ssh/identity.pub у домашньому каталозі користувача. Користувач потім повинен копіювати identity.pub до ~/.ssh/authorized_keys у його домашньому каталозі на віддаленій машині (файл authorized_keys є відповідником традиційному ~/.rhosts і містить по одному ключ на рядок, навіть якщо рядки дуже довгі від цього). Після цього, користувач може реєструватися без необхідності вводити гасло. RSA-автентифікація набагато безпечніша за rhost.

Найзручнішим способом використання RSA-автентифікації, можливо, є у поєднанні з автентифікаційним агентом. Загляніть до ssh-agent(1) для додаткової інформації.

Якщо інші автентифікаційні методи зазнають невдачі, ssh попросить користувача ввести гасло. Гасло буде посланим віддаленому хосту для перевірки, втім оскільки люба комунікація є зашифрованою, гасло неможливо буде прочитати комусь, хто підслуховує в мережі.

Протокол SSH версії 2 ¶

Ті самі автентифікаційні методи доступні й тоді, коли користувач під'єднається, використовуючи протокол версії 2. За умови, що змінна PreferredAuthentications має стандартне значення, клієнт спробує спочатку засвідчитися звичайною, основаною на дозволених хостах, методою; якщо це зазнає невдачі, відбудеться спроба автентифікуватися за допомогою публічного ключа; і, нарешті, якщо перші дві спроби не вдалися, матиме місце інтерактивна автентифікація із введенням даних з клавіатури з перевіркою гасла.

Методa публічного ключа схожa на RSA-автентифікацію, описану в попередньому розділі, і дозволяє використання алгоритмів DSA або RSA. Клієнт застосує приватний ключ ~/.ssh/id_dsa або ~/.ssh/id_rsa для підпису ідентифікатора сеансу і пошле результат серверові. Сервер перевірить, чи відповідний публічний ключ перелічено у ~/.ssh/authorized_keys, і надасть доступ, якщо ключ і підпис дійсні. Ідентифікатор сеансу утворюється зі спільного значення Dіffie-Hellman, відомого тільки клієнту і серверові.

Якщо перевірка публічним ключем зазнала невдачі або не доступна, на віддалену машину можна відправити зашифроване гасло для підтвердження особи користувача.

Додатково, ssh підтримує по-машинну або "запит-відповідь" автентифікацію.

Протокол 2 забезпечує додаткові механізми для конфіденційності (мережний трафік шифрується за використанням 3DES, Blowfish, CAST128 або Arcfour) і перевірки цілісності (hmac-sha1, hmac-md5). Зверніть увагу, що протоколу 1 бракує хорошого механізму забезпечення цілісності даних.

Вхід у систему і віддалене виконання ¶

Якщо ідентичність користувача схвалена сервером, то сервер або виконає вказану команду, або зареєструє користувача і надасть звичайну оболонку на віддаленій машині. Весь обмін даних із віддаленою командою або оболонкою буде автоматично зашифровано.

Якщо надано псевдо-термінал (звичайний сеанс після реєстрації з системою), то користувач може вживати керуючими послідовностями, описаними нижче.

Якщо псевдо-термінал не призначено, сеанс буде прозорим і може застосовуватися для передачі бінарних даних. На більшості систем, надання керівному символу значення "none" зробить сеанс прозорим , навіть якщо використовується термінал.

Сеанс закінчиться, коли команда або оболонка на віддаленій машині завершить роботу і всі сполучення Х11 і TCP/IP обірвано. Статус виходу віддаленої програми повертається як статус виходу ssh.

Керівні послідовності ¶

Якщо було запитано псевдо-термінал, то ssh надає можливість використання деяких функцій за допомогою керівних послідовностей.

Одинарний символ тильди можна послати як ~~, або якщо за тильдою слідує інший символом, відмінним від тих, що описано нижче). Керівний символ повинен завжди знаходитись на початку нового рядка, щоб бути розглянутим як спеціальний. Керівні символи можна поміняти у файлах конфігурації через змінну EscapeChar або на командному рядку опцією -e. (Як правило, керівний символ не відображається під час його введення.)

Підтримуваними послідовностями (припускаючи стандартну '~') являються:

~.

Здійснить відключення.

~^Z

Пошле ssh у фоновий режим (використайте команду fg щоб вивести сесію на передній план).

~#

Надасть список випереджених сполучень.

~&

Пошле ssh у фоновий режим під час виходу, очікуючи завершення випереджених сполучень або сесій Х11 (тільки для протоколу версії 1).

~?

Виведе список керуючих послідовностей.

~B

Пошле сигнал BREAK віддаленій системі (дійсне тільки для протоколу SSH версії 2, і тільки коли протилежна сторона підтримує це).

~C

Відкриє командний рядок ssh. На сьогодні, це дозволяє випередження портів, використовуючи опії -L і -R (дивіться нижче), також відміну існуючого випередження віддалених портів за допомогою -KR порт_хосту.

~R

Запит на додатковий обмін ключами (тільки для протоколу SSH версії 2, і якщо протилежна сторона підтримує це).

Перенаправлення X11 і TCP ¶

Якщо змінну ForwardX11 встановлено до ``yes'' у ssh_config, (або дивіться опції -X або -x нижче). і користувач використовує X11 (зі встановленою змінною середовища DISPLAY), то підключення до дисплею Х11 буде автоматично перенаправлене до віддаленої машини таким чином, що будь-яка Х11-програма, запущена з оболонки (або команди) пройде через зашифрований канал і з'єднання з дійсним сервером Х відбудеться з локальної машини. Користувач не повинен власноруч встановлювати DISPLAY. Перенаправлення з'єднань X11 може бути ввімкнене з командного рядка або у файлах конфігурації.

Значення DISPLAY, встановлене ssh, вказуватиме на машину-сервер, але з номером дисплея більшим за нуль. Це нормально, і відбувається тому, що ssh створює посередницький (проксі) Х-сервер на машині-сервері для пересилання з'єднань через зашифрований канал.

ssh також автоматично налагодить дані з Xauthority на сервері. Для цієї мети він створить випадкові ріп'яшки (cookie) авторизації, збереже їх у Xauthority на сервері і впевниться, що перенаправлені з'єднання передають ці ріп'яшки і міняють їх на дійсні, коли встановленоe справжнє з'єднання . Дійсний автентифікаційний ріп'яшок ніколи відсилається назад серверу (і жоден з ріп'яшків не проходить незашифрованим).

Якщо користувач використовує автентифікаційного агента (змінна ForwardAgent встановлено до ``yes'', або використано -A або -a опції, описані нижче), то підключення до агента автоматично перенаправляється протилежній стороні.

Перенаправлення довільних TCP/IP-з'єднань через захищений канал, можна вказати або на командному рядкові, або у файлі конфігурації. Одне з можливих застосувань перенаправлення TCP/IP - це захищене з'єднання з електронним гаманцем; інше - проходження повз мережний екран (firewall).

Автентифікація сервера ¶

ssh автоматично обслуговує і перевіряє базу даних, що втримує ідентифікацію для всіх машин, з якими колись було сполучення. RSA-ключі машини зберігаються в ~/.ssh/known_hosts. Додатково автоматично перевіряється файл /etc/ssh/ssh_known_hosts щодо відомих хостів. Будь-яку нову машину автоматично додано в користувацький файл. Якщо інформація по ідентифікації машини змінилася, то ssh попередить про це й унеможливить автентифікацію гаслом, щоб уникнути здобуття користувацького гасла "троянським конем". Інше призначення цього механізму полягає в тому, щоб запобігти нападів типу man-іn-the-middle, використовуваних для обходу шифрування. Можна використати параметр StrictHostKeyChecking, щоб заборонити вхід у систему з тих машин, чиї ключі не відомі або змінені.

ssh можна налагодити таким чином, щоб вона перевіряла ідентичність хосту за допомогою ресурсу записів відбитків (SSHFP), що видаються DNS. Для цього необхідно встановити параметр VerifyHostKeyDNS, що керуватиме тим як здійснюються запити DNS. Записи відбитків SSHFP можна відтворити за допомогою ssh-keygen(1).

ssh розпізнає наступні ключі:

-1

Вимагає використання тільки протоколу версії 1.

-2

Вимагає використання тільки протоколу версії 2.

-4

Вимагає використання тільки адрес IPv4.

-6

Вимагає використання тільки адрес IPv6.

-A

Вмикає перенаправлення з'єднання агента автентифікації. Це можна також вказати на по-машинній основі у файлі конфігурації.

Слід обережно ставитись до вмикання перенаправлення агента. Користувачі з можливістю обійти дозволи на доступ до файлів на віддаленій машині (а саме, до сокету домену Юнікс, що належить агентові), можуть дістатися до локального агента через перенаправлене сполучення. Атакуючий не може отримати дані ключів від агента, однак вони спроможні здійснити операції, пов'язані з ключами, що дозволить їм засвідчитись, використовуючи ідентичності, завантажені агентом.

-a

Вимикає перенаправлення з'єднання агента автентифікації.

-b вихідна_адреса

Використає вихідну_адресу локальної машини, як джерело сполучення. Корисно для систем із кількома адресами.

-C

Вимагає стиснення всіх даних (включаючи stdin, stdout, stderr і дані перенаправлених з'єднань X11 і TCP/IP). Алгоритм ущільнення відповідає тому, що застосовується в gzip(1), а рівень стиснення можна регулювати параметром CompressionLevel для протоколу 1-ї версії. Ущільнення даних є бажаним у випадку модемних ліній і інших повільних засобах сполучення, але сповільнить передачу у швидких мережах. Стандартні значення можна встановити на по-машинній основі у файлі конфігурації; дивіться параметр Compression.

-c специфікація_шифру

Вибір специфікації шифру для зашифровування сесії.

Протокол версії 1 дозволяє специфікацію одного шифру. Підтримуваними значеннями являються "3des", "blowfish" і "des". 3des (потрійний des) складається з послідовності зашифровування-розшифровування-зашифровування з трьома відмінними ключами. Він вважається безпечним. blowfish - це швидкий блоковий шифр; він видається дуже надійним і набагато швидший за 3des. Останній, des, підтримується тільки для оберненої сумісності з первинним протоколом 1, що не підтримує 3des. Використання des не рекомендується, через криптографічну слабкість. Стандартним є 3des.

Для протоколу версії 2, специфікацію_шифру може бути визначено як, розділений комою, список шифрів у порядку їхнього пріоритету. Підтримуються "3des-cbc", "aes128-cbc", "aes192-cbc", "aes256-cbc", "aes128-ctr", "aes192-ctr", "aes256-ctr", "arcfour128", "arcfour256", "arcfour", "blowfish-cbc" і "cast128-cbc". Стандартний список складається з

        aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,


        arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,


        aes192-ctr,aes256-ctr

-D порт

Вказує локальне "динамічне" перенаправлення порту на рівні додатка. Це працює шляхом виділення сокету для прослуховування порту на локальній машині, і як тільки відбулося під'єднання до цього порту, його перенаправлено через захищений канал, і протокол додатку потім вирішує куди з'єднається віддалена машина. На сьогоднішній день підтримуються протоколи SOCKS4 i SOCKS5, і ssh поводитиметься як SOCKS-сервер. Тільки користувач root може перенаправляти привілейовані порти. Динамічне перенаправлення портів можна також вказати у файлі конфігурації.

-e ch|^ch|none

Задає керівний символ для сеансів із псевдо-терміналом (стандартний символ - '~'). Керівний символ розпізнається тільки на початку рядка. Якщо за ним слідує крапка, ('.'), це завершить з'єднання; наступна control-Z призупинить з'єднання і два керівних символи підряд передадуть один керівний символ. Ключ -e з параметром "none" скасовує будь-які керівні символи і робить сеанс прозорим.

-F файл_конфігурації

Дозволяє вказати альтернативний файл конфігурації. Якщо конфігураційний файл задано на командному рядкові, системний (/etc/ssh/ssh_config) буде проігноровано. Стандартним конфігураційним файлом користувача, який ssh шукатиме, є ~/.ssh/config .

-f

Примушує ssh перейти у фоновий режим перед самим виконанням команди. Це корисно, якщо ssh збирається спитати гасло або вирази-гасла, але користувач хоче зробити це у фоновому режимі. Це неявно вмикає -n. Рекомендованим способом запуску програм Х11 на віддаленому комп'ютері є щось на зразок "ssh -f host xterm".

-g

Дозволяє віддаленим машинам звертатися до локальних перенаправлених портів.

-I smardcard-пристрій

Вказує, який smardcard-пристрій використати. Аргументом є пристрій, який ssh використовуватиме для комунікації з карткою smartcard, що зберігає приватний ключ RSA користувача.

-i файл_ідентифікації

Вказує файл з якого зчитується ідентифікація (приватний ключ) для RSA або DSA автентифікації. Без задання, це ~/.ssh/identity для протоколу версії 1, і ~/.ssh/id_dsa для протоколу версії 2. Файли ідентифікації також можна зазначити на по-машинній основі у файлі конфігурації. Можна вказати підряд кілька параметрів -i (і кілька ідентифікаторів у конфігураційному файлі).

-k

Забороняє перенаправлення (представлення) ідентифікаційної інформації GSSAPI серверу.

-L [вихідна_адреса

]порт:хост:порт_хосту: Вказує, що заданий порт на локальній (клієнтській) машині який буде перенаправлений до заданої машини і порту на протилежній стороні. Це втілено шляхом призначення сокету для прослуховування порту на локальній машині, можливо прив'язаний до вказаної вихідної_адреси. Кожний раз, як відбувається з'єднання із цим портом, його буде перенаправлено через захищений канал і здійснюється з'єднання до порту порт_хосту віддаленої машини. Перенаправлення портів можна також вказати у файлі конфігурації. Адреси IPv6 можна вказати за допомогою альтернативного синтаксису

     [<i>вихідна_адреса</i><b>/</b>]<i>порт</i><b>/</b><i>хост</i><b>/</b><i>порт_хосту</i> 

-l реєстраційне_ім'я

Вказує ім'я користувача для реєстрації з віддаленою системою. Це можна також вказати на по-машинній основі у файлі конфігурації.

-M

Встановлює ssh у "чільний" режим для спільного використання з'єднання. Зверніться до опису ControlMaster сторінки ssh_config(5) для повного опису.

-m mac-ключ

Додатково, для протоколу версії 2 можна вказати, розділений комою, список алгоритмів MAC (код автентифікації повідомлення) у порядку пріоритету. Для додаткової інформації, шукайте по ключовому слову MAC.

-N

Не виконувати віддаленої команди. Корисна тільки для перенаправлення портів (протокол версії 2).

-n

Читає стандартний ввід з /dev/null (фактично, запобігає читання зі стандартного вводу). Це повинно використовуватися, коли ssh виконується у фоновому режимі. Типовий трюк, використовуваний для запуску Х11-програм на віддаленій машині. Наприклад, команда "ssh -n shadows.cs.hut.fi emacs &" запустить emacs на shadows.cs.hut.fi, з'єднання X11 будучи автоматично перенаправлено через зашифрований канал. Програму ssh буде переведено у фоновий режим. (Це не працює, якщо ssh потрібно спитати гасла або виразу-гасла; також дивіться опцію -f.)

-O кер_команда

Керує основним ущільнювальним процесом активного сполучення. За допомогою опції -O, аргумент кер_команда буде інтерпретовано і передано основному процесові. Чинними командами являються "check" (перевіряє, чи активний основний процес) і "exit" (вимога завершення основного процесу).

-o опція

Можна використати для задання опцій у форматі, використовуваному файлом конфігурації. Це корисно для вказівки параметрів, для яких не існує окремої опції командного рядка. Для повного опису параметрів, перелічених нижче, і їхніх можливих значень, дивіться ssh_config(5).

        AddressFamily


        BatchMode


        BindAddress


        ChallengeResponseAuthentication


        CheckHostIP


        Cipher


        Ciphers


        ClearAllForwardings


        Compression


        CompressionLevel


        ConnectionAttempts


        ConnectTimeout


        ControlMaster


        ControlPath


        DynamicForward


        EscapeChar


        ForwardAgent


        ForwardX11


        ForwardX11Trusted


        GatewayPorts


        GlobalKnownHostsFile


        GSSAPIAuthentication


        GSSAPIDelegateCredentials


        HashKnownHosts


        Host


        HostbasedAuthentication


        HostKeyAlgorithms


        HostKeyAlias


        HostName


        IdentityFile


        IdentitiesOnly


        KbdInteractiveDevices


        LocalForward


        LogLevel


        MACs


        NoHostAuthenticationForLocalhost


        NumberOfPasswordPrompts


        PasswordAuthentication


        Port


        PreferredAuthentications


        Protocol


        ProxyCommand


        PubkeyAuthentication


        RemoteForward


        RhostsRSAAuthentication


        RSAAuthentication


        SendEnv


        ServerAliveInterval


        ServerAliveCountMax


        SmartcardDevice


        StrictHostKeyChecking


        TCPKeepAlive


        UsePrivilegedPort


        User


        UserKnownHostsFile


        VerifyHostKeyDNS


        XAuthLocation

-p порт

Порт сполучення з віддаленим хостом. Це можна вказати окремо для кожної машини у файлі конфігурації.

-q

Тихий режим. Пригнічує всі попереджувальні і діагностичні повідомлення.

-R [вихідна_адреса

]порт:хост:порт_хосту: Вказує щоб порт на віддаленій (серверній) машині був перенаправлений до заданого хосту і локального порту. Це втілено шляхом призначення сокету, що прослуховуватиме порт на віддаленій машині і як тільки відбулося під'єднання до цього порту, це сполучення перенаправляється через захищений канал, з'єднуючись до хосту i порту_хосту локальної машини.

Перенаправлення портів можна так само вказати у файлі конфігурації. Тільки надкористувач може здійснювати перенаправлення привілейованих портів. Адреси IPv6 позначаються альтернативним синтаксисом:

     [<i>вихідна_адреса</i><b>/</b>]<i>порт</i><b>/</b><i>хост</i><b>/</b><i>порт_хосту</i> 

-S кер_сокет

Вказує шлях до керівного сокету для спільного використання з'єднання. Зверніться до опису ControlPath і ControlMaster у ssh_config(5).

-s

Можна використати для виклику підсистеми на віддаленому хості. Підсистеми - це риса протоколу SSH2, яка полегшує застосування SSH як захищений засіб передачі для інших додатків (наприклад sftp(1)). Підсистема вказується як віддалена команда.

-T

Скасовує надання псевдо-терміналу. .T -t Наполягає на наданні псевдо-терміналу. Це можна використати для виконання різноманітних, пов'язаних з екраном, програм на віддаленому сервері, що може виявитись корисним при втіленні сервісів меню. Багатократні опції -t змушують призначення терміналу, навіть якщо ssh не має локального.

-V

Виведе інформацію про версію програми і завершить роботу.

-v

Багатослівний режим. Спричинить вивід ssh повідомлень відлагодження про власний прогрес. Це корисно для зневадження сполучень, автентифікації і конфігурації. Багатократні опції -v (максимум 3) збільшують докладність повідомлень.

-X

Вмикає перенаправлення X11. Це можна також вказати для окремого хосту у файлі конфігурації.

Слід обережно ставитися до перенаправлення X11. Користувачі з можливістю обійти дозволи на доступ до файлів на віддаленій машині (а саме доступ до авторизаційної бази даних X11) можуть дістатися до локального дисплею X11 через перенаправлене сполучення. Атакуючий потім може здійснити такі речі як моніторинг натиснення клавіш.

З цієї причини, перенаправлення X11 являється частиною обмежень розширення SECURITY X11. Зверніться до опції -Y та директиви ForwardX11Trusted (дивіться ssh_config(5)) для додаткової інформації.

-x

Забороняє перенаправлення X11.

-Y

Дозволяє перенаправлення X11 тільки довіреним хостам.